COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		This short document lists the  currently outstanding problems
C00017 ENDMK
C⊗;
	This short document lists the  currently outstanding problems
associated with the  design of HAL.  As these are solved, 4R.DOC will
be changed to  reflect the solution,  and they  will be removed  from
this list.
	RCB is responsible for this file ... please feel free to add
items or comments to the list, but do not erase things.


	LANGUAGE FEATURES
	We need some "nice" way of describing common control flow
such as simple RETRY when something goes wrong and the operator
remedies the situation.  This emphasizes the need for clearly
understanding when ASSERTIONS are needed and what control flow is
possible (without JUMPS) to handle these situations.

	What about comments??? There seem to be a variety of ways
to provide comments which extend over ;'s, etc:
	(1) use {} or ⊂⊃ ... but trouble with paired moves
	(2) use COMMENT ⊗ _________
			  _________
			  _________⊗
	(3) let the user REQUIRE the macro delimiters, comment
	    delimiters ...

	There seems to be a general problem concerning the "generality"
of neat operators ... education about how to use them ... and clarity
of expression ... we definitely need to tutor each other and check
the XMPLES.DOC file ... the memo segments being written should be
tutorial in that they show what concepts are being used and essentially
how express them (for simple cases and more complicated cases)

	DEPROACH's ... automatic mass calculations or any other
"automatic" data base updating ... can the user set up ANTECEDENT
theorems ... consequent theorems???  ... demonstrate how property list
types of things can be done using assertions.

CONFUSION ABOUT ON MONITORS
	We say a block is done when no interpreters remain.  Question:
	ON COND1 DO
		BEGIN
		ON COND2 DO FOO;
		ON COND3 DO BAZ
		END
Do COND2 or COND3 stay around for any length of time?  This problem
really bugs me.  I want to say that COND2 and COND3 will go away
whenever COND1 was scheduled to go away, but how do you do that?
Do we really need to explicitly start an interpreter within the
conclusion of an ON, so that we can keep straight who is responsible
for which ON?  Like:
	ON COND1 DO
		BEGIN
		ON COND2 DO FOO;  COMMENT:  Done at on-level;
		ON COND3 DO 
			BEGIN
			START;  COMMENT:  Makes an interpreter;
			BAZ
			END
		END

	DATATYPES AND VARIABLES

	Need  syntax   for  graph   structure  manipulation   macros,
principally the vine-to-rake  transformation and deletion.  We should
also write down the algorithms needed.

	EXPANDER STUFF, WORLD MODELLING
	We need  a syntax  for  "let the  expander, in  his  infinite
wisdom, select a frame for me following  the constraints I have given
it". RCB: That sounds about right to me!!!

	Do  we want an ASSERT  ALWAYS construct to  make an assertion
valid for all world models during planning? RCB: Why?  save compiler
checking? save reassertions? or catching accidental changes to that
assertion?


	WRITING THE PAPER

	RCB: (NOTE that the papers for the 4th International AI Conf.
are due by October 1, 1974!!!  I think some portion of this should be
there.)

	The world is plastic; things flow a bit over time.
	The  language is to be accessible  to a technically competent
factory worker.

	DETAILS OF THE RUNTIME

	We  have not  worked  out the  syntax  for the  runtime  code
driving ON monitors.

	ODDS AND ENDS